NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/7071

Internet Message Format | 1996-08-05 | 3.8 KB

Path: src.honeywell.com!not-for-mail
From: [e-mail] (Lee Graba)
Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
Subject: Re: C/C++ knocks the crap out of Ada
Date: 20 Feb 1996 12:29:38 CST
Organization: Honeywell Technology Center, Honeywell Inc.
Message-ID: <4gd3ui$[e-mail]>
References: <4etcmm$[e-mail]>
  <4f4ptt$[e-mail]> <4g1b7n$[e-mail]>
  <[e-mail]> <[e-mail]>
  <[e-mail]> <[e-mail]>
NNTP-Posting-Host: zero.htc.honeywell.com
X-Newsreader: knews 0.9.3
In-Reply-To: <[e-mail]>
To: Ken Garlington <[e-mail]>

In article <[e-mail]>,
    Ken Garlington <[e-mail]> writes:
>Jon S Anthony wrote:
>>
>> So, does this mean that there are _no_ confirmed cases of probes lost due
>> software?  If so, I'm impressed as software has just plain _got_ to be
>> the weakest link in the chain.  1/2 :-)
>
>Actually, I would say that system requirements are the weak link in the chain,
>although the errors often tend to occur in software these days since more
>requirements (and particularly the harder, more volatile requirements) tend to
>be put in software.
>
>Three cases near and dear to my heart:
>
>For years, I have heard the story about how a "bug" in the F-16 flight control
>computer caused it to roll to an inverted position when crossing the equator. I
>have never found anything authoritative that exactly described the circumstances
>(if anyone has this information, let me know); but there are two points to be
>made about this:
>
>  1. Until relatively recently, the F-16 flight control computer didn't have any
>     software in it. It was an analog computer.

Actually, the F-16A had a hybrid flight control computer.  The primary flight
control functions were performed by an analog computer, but some flight control
gains were scheduled with respect to flight condition by a digital computer and
fed to the analog computer.  However, setting gains should not cause the above-
described phenomenon.

If such a thing did occur, it would probably be due to the Navset, which is
usually a separate digital computer whose responsibility is to take
measurements and then compute positions and attitudes, and associated rates.
A software error here might cause a problem, if say, it was telling the flight
control computer that it was flying straight and level, and suddenly told it
that it was really upside down.  The flight control computer would then try
to right the plane, since it doesn't know good information from bad.

I have heard the above story, as well, but don't know if it is true.

>
>  2. Some people believe they heard this story in terms of the behavior of a
>     handling qualities _simulation_ of the flight control system, in which
>     the environment model only contained a part of the northern hemisphere. Someone
>     decided to see what happened when you "flew off the edge of the earth."
>
>The other two cases are more recent and involve pilot-induced oscillations leading
>to an aircraft crash. In both cases, the press widely reported (in at least one
>case, quoting a senior executive at one company) that "the software got confused."
>However, the error in both cases was due to an interaction of the control law model,
>which can be implemented in either hardware or software, and the pilot. (The pilot
>will probably say the control laws were wrong; the control law people will probably
>say that the pilot operated the system outside its' limits. Both are probably right
>:). Nonetheless, because the behavior occured in software, that's what gets the
>blame.
>
>Dr. Levison's "Safeware" defines far issue much better than I just did, BTW.